IBIS Macromodel Task Group Meeting date: 07 August 2018 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan * Stephen Slater Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft: * Walter Katz * Mike LaBonte SPISim: * Wei-hsing Huang Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the July 31 meeting. Radek moved to approve the minutes. Bob seconded the motion. There were no objections. ------------- New Discussion: Question from the Quality Task Group regarding BCI_State (BIRD147.6): Mike L. and Bob sought the group's opinion on what, if any, checking ibischk should perform on the value of BCI_State in the .ami file. Mike said he was leaning toward none. Arpad asked if the spec defined the value in the .ami file as a place holder, similar to DLL_ID? (it does not). Radek noted that in fact it is defined as Usage InOut and Format List. The five valid values in the list are "Off", "Training", "Converged", "Failed", "Error". Radek noted that the user should select "Off" or "Training" at the start of the simulation (see BCI_State Definition:). Arpad noted that since it is defined as a List the user must make a selection, and if they don't the EDA tool has to pass the default value to the .dll. The .ami file will contain the list definition, not some unused Value. Radek agreed. Bob noted that the parser could just check for valid values in the List. Single-ended applications of algorithmic modeling: Clock Forwarding - Fangyi noted the proposal to use the existing clock_times argument in AMI_GetWave() to send clock ticks into the .dll, and wondered if we should consider other solutions. Walter noted that if people object to using the existing clock_times bi-directionally, then the easiest thing to do would be to create a new GetWave() call that has another pointer argument to an input array of clock ticks that go with the data. The .dll then fills the existing clock_times with the clock ticks that it chooses, so it might be easier to add a new GetWave() signature with a separate pointer to input clock_ticks. Fangyi noted that he preferred to go one step further and pass the entire clock waveform into the .dll, not just the clock ticks. Arpad asked if the clock waveform would have the same sampling as the data waveform. Fangyi said it would. Arpad asked if we would need to pass in threshold information, too. Walter said we could do the same thing we do for the Tx stimulus waveform (+0.5 to -0.5 with a crossing at zero). Arpad asked if this solution would be general enough. Walter said the DDR5 clock is differential. Fangyi asked if Arpad was worried about the possibility of a single-ended clock. Arpad asked if we need to consider it, in order to provide a more general solution than something specific to DDR5. Randy said he didn't think we would encouter a single-ended clock at the data rates we are working with. Walter stated that it would be easy to implement a way to pass in clock times. The question, however, is whether we should consider doing it without someone asking for it. Is there a model maker who wants to have the input clock waveform? The requestor would have to describe how they want the EDA tool to generate those input clock times. Arpad returned to Fangyi's suggestion of passing in the clock waveform itself. The reason to pass the entire waveform was that the model might do something different with it than the EDA tool would. But, if we were to keep it simple and pass clock waveforms as -0.5 to +0.5 with a zero crossing, why would it be useful to pass the waveform itself? What could the model do that the EDA tool couldn't with that simple waveform? Walter noted one possibility was that the waveform would have a slew rate, and derating tables could include the slew rate of the waveform. So, Walter said maybe it was better to just pass in the DQS waveform itself and let the model maker's .dll figure it out. Arpad noted that if we were going to change the GetWave() footprint, then we might as well consider addressing other issues that may be resolved more appropriately with a footprint change. Walter noted that he would like to add a parameters_in string to GetWave(). Stephen noted that current practice is for EDA tools to calculate the Vref per the spec. But now, with equalization on the receiver, internal to the DRAM you have a DFE that is being clocked externally but also uses the Vref in determining the DFE tap settings. So, he wondered if you can have a single AMI model treating everything independently, or if you need a new AMI model that has multiple inputs and lets the .dll work out internally what the correct Vref should be and what the DFE settings should be for each DQ. He asked for DRAM vendors to comment on whether this would be more complicated than is necessary. Walter noted that Vref is important inside the .dll, even though most initial applications of AMI to DDR5 assume the AMI waveform is centered around zero. The only way you can get the Vref information to the Init() function is to pass it in along with the impulse response. This is straightforward for the tool, since the IR is typically calculated from a step response, and Vref is the mid-point of the step response. For GetWave() we have the choice of whether to have the waveform centered on zero or to leave the Vref in the waveform. Walter noted that GetWave() needs the absolute value of the incoming voltage waveform because it could get into saturation if your Vref were very high and you tried to add too much from the DFE. Walter also suggested that we could instead pass a step response to Init() and let it calculate Vref and the IR for itself. Arpad noted the rise/fall asymmetry issue and suggested we might address it in a more robust manner if we are considering changing the AMI footprint. Fangyi agreed, and said it would be a good idea to have a new Init() that takes more than one IR. Walter proposed a new Init() that takes rising and falling step responses. Then you don't need to pass Vref. Fangyi agreed. Arpad noted the redriver flow discussions and noted that some solutions to the flow issue had involved changing the AMI footprint. Walter said a new Init() could take rising and falling step responses, drop the cross talk terms, and allow both the Tx and Rx to return their linear and non-linear(DFE) equalization terms. The EDA tool could then perform all the cross talk convolutions. Michael M. noted that someone had once proposed an additional "Stat" function that would handle statistical flow and allow the Init() function to focus solely on initialization. Mike L. noted that he and Todd proposed it because they'd encountered scenarios where it might have been better if Init() only handled initial setup and not IR processing too. Arpad noted that this could help with redriver flow issues, as there had been some proposals to call Init() more than once, but this was difficult because Init() performed initial setup and not just IR processing. Arpad suggested we create a list of the current issues with the AMI flow and possible solutions if we changed the AMI footprint. Walter noted that none of the issues yet discussed would provide a solution to the problem of providing a correct input waveform to Rx GetWave() when you have a single-ended DQ with different rise and fall rates. Walter said the EDA tool is responsible for generating this waveform input to Rx GetWave(), and he reiterated that he and Ambrish think the tool can do it without any changes to AMI. Walter noted Fangyi says the spec is broken. Walter acknowledged that it is incomplete, but suggested that anyone who wants to change AMI should write the BIRD. He and Ambrish don't think it's necessary. Fangyi noted that we all agree that what the spec says is incorrect for a DDR5 scenario. If the system has different rising and falling edge rates, then it is not LTI. If a tool vendor says they can convert Tx GetWave() output to Rx GetWave() input, then that particular process is based on some assumptions. If you have different assumptions you'd have a different approach to the algorithm. There is no first principle theory that lets you do that in a general way, and whatever you are doing is based on some assumptions or approximations. Radek noted that there is not sufficient information in the AMI flow to create the correct input waveform. Yes, if you had the correct input waveform the Rx GetWave() could handle it properly. But there is not sufficient information to guarantee that you've created the correct input. Walter said if a tool vendor can give their user arithmetic to tell them how accurate the model would be in each given scenario, then the user can decide if that's good enough. Fangyi did not think such an accuracy guarantee was possible. Arpad asked if someone would create a list of the issues we would like to fix in AMI that could possibly be addressed with a footprint change. Arpad noted that he would like the redriver flow issue included in this list. He noted that Walter's original redriver flow proposals had been considered incomplete, and competing suggestions relied on footprint changes. Fangyi took the AR to draft such a list. Stephen noted that Walter had proposed several solutions that could be included in the list. Mike L. asked if the clock forwarding issue couldn't be handled by a second AMI model dedicated to the diff pin pair that received the clock. That Rx AMI model could process the clock waveform and return clock ticks. The EDA tool could then take those returned clock ticks and pass them in to the AMI model handling the data waveform. Walter said one complication is that the phase of DQS and DQ are often determined by the transmitter not the receiver. He reiterated that he would like to hear someone developing DQ AMI models describe how they would use the clock waveform input. If no one knows how they would use it, why put a lot of effort into defining it at this point? Arpad asked Michael M. and Randy if they would take an AR to investigate this. They agreed. - Mike L.: Motion to adjourn. - Walter: Second. - Arpad: Thank you all for joining. AR: Fangyi to draft a list of AMI issues that could be addressed by an AMI footprint change. AR: Randy to investigate if/why/how a clock waveform input might be used. AR: Michael M. to investigate if/why/how a clock waveform input might be used. ------------- Next meeting: 14 August 2018 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives